More memory is being embedded into system-on-chip (“SOC”) devices in order to provide increasing functionality. Many SOC devices have more than 50% of their area devoted to embedded memories. Ensuring these memories are valid and operating correctly is of the upmost importance for producing SOC devices. In addition, as memory content increases, the memories become more susceptible to defects and variations in the chip parametric as technology feature sizes decrease. Memory failures adversely impact the ability of SOC devices to operate in their intended manner. In order to account for such failures, embedded memories are typically designed to have redundant memory in the form of additional columns, rows and/or locations. The redundant memory can be dynamically substituted for locations within a particular memory that have been diagnosed during a testing phase as exhibiting failure characteristics.
When any one of the cores of a SOC device is powered up, information is conveyed to the memory of that powered-up core, instructing the powered-up core to access a working redundant location within the redundant memory whenever a failed memory location is sought to be accessed. As long as the redundant memory locations may be accessed in lieu for failed memory locations, these memories are considered to be repaired and available for use within the SOC device.
Any reasonable SOC solution requires extensive memory repair capability along with the ability to adjust hardware settings (e.g., timing and voltage levels, and other system settings) based on manufacturing test results. These test results are typically stored in nonvolatile storage elements (typically, but not limited to, efuses) such that the information gathered during manufacturing test is available for use for the final system application. Electronically programmed fuses are typically used to repair the embedded memories with repair data that enables redundant memory locations to be accessed in place of failed memory locations. Typically, a blown fuse is represented by a high logic value, while an intact fuse is represented by a low logic value.
Since there are many cores to provide such information to on a SOC device, the requirement to collect and distribute such repair and setting adjust information in the respective SOC device raises significant difficulties. For instance, the cores can be physically scattered around the SOC device. Furthermore, the cores may serve different functions and may be active at different times. As such, the cores may also be powered down when inactive, as is typical in many low power mobile applications. These factors need to be considered when downloading repair and setting adjustment information stored in efuses to the cores.
Current art may have a separate fuse controller for each of the cores. The separate fuse controllers can download the repair and setting adjustment information for their corresponding core. Whenever a core is powered on, the corresponding fuse controller for that core downloads the repair and setting adjustment information to that core. A considerable drawback of this approach is that having separate fuse controllers requires duplicating circuit blocks, which leads to inefficient use of the SOC device area.
Another solution is to use a single fuse controller with multiple fuse bays, where each separate fuse bay (or other blocked off data block) corresponds to a separate core. Thus, the storage of repair and system information for a particular core cannot be intermingled with the storage of repair and system information for another core in a single fuse bay. Whenever a core needs the repair and system information downloaded to the core, the fuse controller can find the corresponding fuse bay and download all the data from that fuse bay to the core without regard to whether any data in that fuse bay was meant for another core.
Two major issues can arise from such design. First, having multiple fuse bays may lead to inefficient use of the SOC area since certain ones of the fuse bays may have a significant amount of unused memory storage. Second, powering up of individual cores may become difficult if the cores are coupled to a single fuse controller. A method of collecting data from the different cores and shipping it to the fuse controller is often employed via a serial interface or a parallel (addressed) interface. The issue with a serial interface is that all cores in the serial shift path need to be powered up, which cannot always be supported.
Therefore, a fuse management system that supports a single centralized fuse controller with a single fuse bay to handle multiple cores independently is highly desired.